COMMENT ⊗   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	ebos.2[w86,jmc]		Detailed ideas for ebos
C00007 ENDMK
C⊗;
ebos.2[w86,jmc]		Detailed ideas for ebos

I think we should try to plan EBOS rather thoroughly before we
start building it, and I would prefer to begin with how it looks
to its users.

1. An idea.  We need a general way of handling "indexicals".  The
term is taken from linguistics and refers to words like  now  and
here  and  I  and  you.  In EBOS indexicals refer, for example,
to the current file, the current position of the cursor, etc.  The
point is that each of these is a synonym for a complex name, and
what name it is a synonym for depends on context.  Perhaps my ideas
on a formal theory of context may be useful here or this concrete
problem may help refine those ideas.

2. Perhaps we should begin with the editor.  I think we should
imitate EMACS in making the main mode one in which characters typed
go directly into the text.

3. modifiers.  The Common Lisp syntax for modifiers is to include
them as additional arguments to a function preceded by a special
symbol.  Unix precedes command line modifiers by a minus sign.
My grade school teacher defined adjectives as modifiers of nouns.
Consider "alleged criminal".  Clearly it isn't a kind of criminal
but is a modification of the concept.

In EBOS modifiers give rise to two questions.  One is notation,
and the other is meaning.  I propose that the meaning of a modifier
is a function applied to the syntactic entity being modified.
In most cases the function will be rather trivial, and we need to
check whether preserving the generality costs too much.  Probably
it won't.  The other problem is what syntax to use.  Something
like the way Unix does it seems reasonable.


May 9
The full Lisp syntax is often too lengthy.  There needs to be
a systematic way of introducing syntactic sugaring.  For example,
there needs to be a systematic way of introducing other punctuation
than full parenthesization.

Digression perhaps: Consider the notion of a syntax stable with
respect to a certain class of additions, i.e. nothing becomes
ambiguous when an addition of this class is made.  Lisp syntax
is more stable than lighter syntaxes that allow shorter expressions.
Perhaps it is sometimes decidable when an addition to a syntax will
produce ambiguities.

May 20 - Tasks.

Our near term goal should be to produce specifications.  We probably
don't need to use the RT for this at all.  These specifications
should include the following.

	1. The unsugared commands of the operating system and
the editor.

	2. The principles of syntactic sugaring for both the
operating system and the editor.  Most likely these can be the
same.  These include the principles for retrieving output and
re-editing input.  Some explicit statement about the state of
mind changes of the user are needed.

	3. The principles of semantic sugaring.  What is actually
done that corresponds to the execution of assignment statements
in the command language.

We should check out the LISP mmchine opterating system.